Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/automations-prd.md`:
- Around line 245-249: The documentation for the `POST
/api/automations/{id}/run` endpoint incorrectly states that it returns a
`session_id`, but the actual implementation returns a `202 Accepted` status with
a status payload and completes asynchronously. Update the documented response
for this endpoint in the HTTP API section to accurately reflect the actual
behavior: specify that it returns `202 Accepted` with a status payload rather
than a `session_id`, and clarify that the operation completes asynchronously
instead of returning immediate results.
- Around line 195-211: The PRD section on agent_create tool describes a blocking
request/resolve card flow with user confirmation before database writes, but the
actual implementation in internal/tools/automation_tool.go writes directly to
AutomationStore without any request blocking, and internal/web/automation_api.go
provides no request-id resolve endpoint. Update the PRD section to either
accurately reflect the current implementation (disabled-by-default mode with
direct writes), or explicitly mark the card machinery,
RequestAutomation/ResolveAutomation handlers, and blocking channel mechanism as
follow-up work items, ensuring implementers understand the actual security
contract in place rather than building against the described but unimplemented
flow.
- Around line 53-80: Add blank lines before and after each markdown table to
comply with markdownlint rules. Specifically, ensure there is a blank line
before the table header and after the closing row in all three tables (屏
A：自动化创建弹窗, 屏 B：自动化列表页, and 屏 C：模板页), as well as in the additional tables at
lines 233-242 and 285-297. Additionally, locate the fenced code block in section
§9.4 and add an appropriate language tag (such as yaml, json, python, etc.)
after the opening triple backticks to fix the missing language specification.
- Around line 91-95: The document contains conflicting specifications about lock
topology. Section D4 states the scheduler election lock is reused as the store
write lock, but sections §10.4 and others (also see lines 220-230, 290-292)
describe a two-lock topology where the election lock is separate from the store
write lock to avoid starving short writes. Decide on one final lock topology
(either reuse the election lock as store write lock per D4, or split into two
separate locks), then update all related sections including D4, D7, and the
problematic sections at 220-230 and 290-292 to consistently reflect that choice.
Ensure the store/scheduler contract clearly describes the chosen topology
throughout the document.

In `@internal/automation/store.go`:
- Around line 178-210: The List(), Get(), and State() methods serve stale data
because they only read from in-memory maps (defs and state) that are refreshed
exclusively when the current process performs writes via loadLocked(). In a
multi-process setup, changes made by other processes become invisible to the web
server. To fix this, add a loadLocked() call at the beginning of each read
method (List, Get, and State) while holding the mutex lock to refresh the cache
from persistent storage before reading and returning the data, ensuring these
methods always serve current information regardless of which process made recent
changes.

In `@internal/automation/validate.go`:
- Around line 101-103: The IsLocalPath function currently accepts both absolute
and relative paths by only checking if the path is non-empty and lacks a URL
scheme separator. Since ValidateAutomation expects absolute paths to prevent
unintended execution against the scheduler's working directory, modify
IsLocalPath to additionally validate that the path is absolute. Use the
filepath.IsAbs function from Go's standard library to enforce this check,
ensuring only absolute paths return true.

In `@internal/command/automation.go`:
- Around line 49-53: The automation command currently writes directly to stdout
using fmt.Println, fmt.Fprintln, and os.Stdout instead of routing through
Cobra's command writer methods. Replace all direct stdout writes with cmd.Print*
methods (cmd.Println for direct prints, cmd.PrintErrln for errors) and replace
os.Stdout references with cmd.OutOrStdout() when creating writers like
tabwriter.NewWriter. This applies throughout the file at the lines mentioned:
49-53, 60-61, 83-90, 100-104, 128, and 148, ensuring all output is properly
routed through Cobra for testability and control.
- Around line 45-46: Raw errors returned in the automation command are not
wrapped with context information. Locate all error return statements in the file
(at lines 45-46, 75-77, 121-127, and 142-147) and wrap each raw error with
fmt.Errorf using the pattern "automation: %w" to provide command-specific
context that preserves the failure origin while maintaining the underlying error
for debugging purposes.

In `@internal/tools/automation_tool.go`:
- Around line 67-70: After determining the `project` variable value (whether
from `in.ProjectPath` or `t.env.Pwd()`), resolve it through `env.ResolvePath()`
before passing it to `store.Create()`. This normalization step converts relative
paths to absolute paths and logs any path-escape warnings. Apply the resolved
path result back to the `project` variable so that the persisted value follows
the tool development guidelines for path handling.

In `@internal/web/automation_api.go`:
- Around line 256-288: The sort.Slice comparison function in the automation API
only sorts by StartTime, but since RFC3339 has second-precision, multiple runs
can share the same StartTime. Combined with random map iteration order in Go,
this causes non-deterministic ordering. Fix the sort.Slice comparison function
to include a stable tiebreaker when StartTime values are equal; add a secondary
comparison by SessionID (or another stable identifier) so that runs with
identical StartTime values maintain consistent relative ordering across
pagination requests using the before cursor.

In `@internal/web/server.go`:
- Around line 249-257: In the rootCtx() method of the Server struct, replace the
nil return statement with context.Background() to ensure a non-nil context is
always returned. This prevents panics in downstream callsites that pass
rootCtx() directly to context.WithTimeout and exec.CommandContext, which both
panic when receiving a nil context as their parent.

In `@web/src/components/AutomationEditorDialog.vue`:
- Around line 290-307: The CSS styles in this component contain hardcoded hex
color values instead of using CSS custom property tokens. In the .form-error
class, replace the hardcoded fallback color `#dc2626` with the --color-destructive
token. In the .btn-primary class, replace the hardcoded color `#fff` with the
--color-on-primary token. These changes ensure all colors derive from the theme
tokens defined in src/styles/tokens.css for consistent theming across the
application.
- Around line 106-109: The AutomationEditorDialog.vue component contains
hardcoded English strings for validation error messages (such as 'Name is
required.', 'Prompt is required.', and 'A project is required (no-project
automations cannot run unattended).') that are not localized. Replace all
hardcoded user-facing strings throughout the component, including the validation
error messages assigned to localError.value in the form validation checks and
any labels, actions, or hints in the template, with vue-i18n translation keys
using the $t() function to enable proper localization for non-English locales.

In `@web/src/components/AutomationsView.vue`:
- Around line 238-249: Replace all hardcoded hex colors with CSS custom property
tokens from src/styles/tokens.css. In the .ok class, replace `#16a34a` with the
appropriate success color token. In the .err class, replace `#dc2626` with the
corresponding danger or error color token variable instead of relying on the
fallback. In both the .run-btn and .btn-primary classes, replace the hardcoded
`#fff` color with --color-on-primary for text on primary background fills,
following the coding guidelines for color tokenization.
- Around line 80-170: The AutomationsView.vue component contains numerous
hardcoded strings throughout the template that prevent localization. Replace all
user-facing text strings with locale key references from the app's i18n system.
This includes: button labels like "New automation" and "Edit", headers like
"Your automations" and "Recent runs", empty state messages, filter options like
"All", "Success", and "Failed", placeholders, status labels, and descriptive
text like "Use agents to handle recurring work on a cadence you choose." and
"Start from a template — pick a project and confirm." Use the appropriate i18n
syntax (typically $t() in Vue) to reference the locale keys instead of embedding
strings directly in the template.

In `@web/src/stores/automation.ts`:
- Around line 60-62: The setEnabled function in automation.ts performs a
full-object update by spreading stripDerived(item) which can overwrite newer
fields if the item object is stale, causing lost updates. Modify the update call
within setEnabled to only pass the enabled property directly (as { enabled })
instead of spreading the entire stripDerived(item) object along with it,
ensuring only the toggle state is updated without affecting other fields.

---

Nitpick comments:
In `@internal/automation/store.go`:
- Around line 388-398: The writeJSONAtomic function lacks explicit file
synchronization (fsync) calls to ensure data is durably written to disk before
the rename operation, which can lead to data loss on crash in some filesystems.
After successfully writing the temp file with os.WriteFile, open the temp file,
call Sync() on it to flush data to disk, and optionally sync the parent
directory before performing the os.Rename operation to improve crash durability
guarantees.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@web/src/components/ChannelsView.vue`:
- Around line 228-400: The CSS in the style block contains multiple hardcoded
hex color values that violate the coding guideline requiring all colors to come
from design tokens. Replace the hardcoded colors in the following locations: the
fallback `#fff` in the .btn-primary class color property, the `#07C160` and `#fff`
hardcoded values in the .wc-btn.approve class, and the `#07C160` used in the
.wc-pill class color and background color-mix function. Use appropriate design
tokens from tokens.css (such as --color-success for the WeChat green,
--color-on-primary for the white/light color, and similar tokens) to replace all
hardcoded hex values.

In `@web/src/components/Sidebar.vue`:
- Around line 426-458: The nav-ic class is being used to size the PlusIcon,
SparklesIcon, and SignalIcon elements in the sidebar header nav-row buttons,
which violates the coding guideline to use Tailwind utilities for icon sizing.
Replace the nav-ic class usage on each of these icon elements with appropriate
Tailwind sizing classes (such as w-5 h-5 or w-4 h-4 depending on the intended
size), then remove the width and height CSS rules from the nav-ic class
definition in the stylesheet to complete the migration to Tailwind utilities.

In `@web/src/i18n/locales/zh-Hant.ts`:
- Line 38: The Traditional Chinese translations for "channels" terminology are
inconsistent across the file. The entries at lines 38 and 66 use `通道`, but the
`settings.tabs.channels` key uses `頻道` for the same concept, which creates
confusion in navigation and settings paths for users. Identify all occurrences
where "channels" is translated in the zh-Hant.ts file (including the `channels`
key around line 38, the second occurrence around line 66, and the
`settings.tabs.channels` entry) and ensure they all use the same consistent
Chinese term throughout the file.

---

Nitpick comments:
In `@web/src/components/MenuSelect.vue`:
- Line 13: The import statement for ChevronUpDownIcon and CheckIcon uses a
grouped barrel import from '`@heroicons/vue/24/outline`' instead of per-file
subpath imports required by the guidelines for tree-shaking optimization.
Replace the grouped import statement with individual per-file subpath imports
where each icon is imported from its own dedicated path (e.g., import
ChevronUpDownIcon from '`@heroicons/vue/24/outline/ChevronUpDownIcon`' and import
CheckIcon from '`@heroicons/vue/24/outline/CheckIcon`' or similar subpath
pattern).

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@design/automations-redesign.html`:
- Line 1000: The switch markup uses self-closing spans, which is invalid for
non-void elements and can lead to parser-dependent DOM structure. Update the
repeated switch templates in the automation redesign HTML so the switch-knob
element uses an explicit opening and closing span tag, and apply the same fix to
every matching instance in the affected markup.
- Line 1036: The automation title contains a typo in the card-name text used for
the stale issues workflow. Update the string in the relevant card markup so
“Triange stale issues” becomes “Triage stale issues”, and make the same
correction in the other duplicate occurrence referenced by the review comment.
- Line 905: The `.btn-danger` styles are using `var(--color-on-destructive)`
before that custom property is defined, so update the theme/token definitions to
declare `--color-on-destructive` first and ensure it is available where
`.btn-danger` is applied. Check the CSS variable block that defines the color
palette in the same stylesheet and add the missing token there, keeping the
existing `background: var(--color-destructive)` usage unchanged.

In `@web/src/App.vue`:
- Around line 50-53: The active run detail is holding a stale run snapshot
instead of tracking the refreshed store state. Update the App.vue flow around
activeRun, showRunDetails, and the run detail binding so the selected run is
derived from automationStore.runs (matched by id) whenever the store refreshes,
rather than keeping the originally clicked object. Make sure the detail header
and status/duration/error fields always read from the current store record, and
adjust any related computed/watch logic used in the active run selection.

In `@web/src/components/AutomationRunView.vue`:
- Line 315: The inline color fallback in AutomationRunView’s status-chip styles
still hardcodes a color-mix value instead of relying on design tokens. Remove
the component-level fallback from the .status-chip.running and related
status-chip rules, switch them to token-only custom properties, and add the
missing accent token definitions in src/styles/tokens.css so all colors are
sourced from tokens only.
- Around line 120-121: The replay cleanup in applyEntries is incorrectly
finalizing unmatched tool_call entries, which breaks live sessions by marking
in-flight calls as done too early. Update AutomationRunView’s applyEntries
handling so only finished-run replays close out unresolved pending tool calls,
and leave them active during live sessions until their result entry arrives. Use
the pending collection logic in applyEntries and the tool_call status update
path to scope this behavior correctly.
- Around line 151-158: The stopRun() handler in AutomationRunView.vue is forcing
running.value to false even when api.stop(props.run.session_id) fails, which
makes a failed stop look like the run stopped successfully. Update stopRun() so
the catch path surfaces the error instead of changing the UI to stopped, and let
the existing polling/state refresh confirm when the run has actually terminated.
Keep the success path in stopRun() unchanged and preserve the run state until
the API call succeeds or polling updates it.

---

Outside diff comments:
In `@internal/command/web.go`:
- Around line 355-373: buildPlanTools currently always includes the interactive
ask_user tool, which can leak back into unattended plan-mode automation. Update
the buildPlanTools helper in web.go to apply the same interactive-tool filtering
used by dropInteractiveTools, or conditionally skip tools.NewAskUserTool when
running in the unattended path so planMode cannot reintroduce an interactive
tool.